Existing Messaging Based Middleware Architectures
Message based middleware provides a “message layer” between communicating services, thus abstracting the underlying operational environment that each service runs on. In other words, the “message layer” acts as a middleman in exchanging messages between services. FIG. 1 shows a high level representation of message based middleware. In FIG. 1, four services communicate via a common middleware platform. Each service may run on different platforms (e.g., hardware platforms, operating systems, etc.). The middleware abstracts the underlying operational environment of each service so that they can communicate via some defined messaging protocol.
There are many message based middleware architectures. Middleware architectures can include features such as message queues, publish/subscribe, and message brokers. A middleware layer can be based on the concept of a message queue. Queue based middleware architecture can take many different forms; there may be a single shared queue that is used to send messages to all services, a dedicated queue for each service to receive messages from, or a dedicated queue for each service to send messages to, among other techniques. In a publish/subscribe model, messages are sent (published) to a destination in the middleware. The destination depends on the message “topic” (sometimes called channel). Services that want to receive messages related to a particular topic “subscribe” to the topic. Topics may be related to the message type (debug, alarm, warning, or task request). The message broker may be implemented with a number of queues, as a publish/subscribe architecture with a number of topics, etc. The term message broker is a part of a message bus that commonly refers to the entity that receives all messages and distributes all messages.
Message Types
Messages sent and from or to a middleware broker may be characterized in several different ways. Four common types of messages are send messages, receiving messages (blocking), receiving messages (non-blocking), and notifications. Send Messages are sent to a broker by a service. Once the service sends the message to the broker, the service expects no response and execution of the service continues. Blocking messages are messages that will cause the service to pause (block) until the service receives the message. For example, if a service attempts to read a message from a broker, or queue, and the message is not ready, then the service's execution will block. Non-blocking messages are messages that will not cause the service to pause (block) until the message is ready. For example, if a service attempts to read a message from a broker, or queue, and the message is not ready, then the service's execution will continue until the message is ready. When a service attempts a non-blocking read, it may provide the broker with a callback function that may be called when the message is ready. Notification messages are messages that the broker sends to a service as a result of some previous request. For example, the previous request may have been a non-blocking read attempt or a subscribe request.
Message Bus Protocols
Advanced Message Queuing Protocol (AMQP) is a message bus protocol. FIG. 2 shows the relationship between AMQP Exchanges and Queues. An AMQP Exchange accepts messages from a service and routes the message to one or more Queue. The Exchange can be designed to route the message based on a static rule (e.g., send the message to these 5 services), based one whatever queues bind themselves to the exchange, based on the message topic, or based on values in the message header.
The Message Queuing Telemetry Transport (MQTT), e.g., reference OASIS MQTT V3.1.1 Committee Specification 01, 18 May 2014, is a message based middleware protocol. MQTT is a low overhead message queuing and transport protocol tailored for constrained devices and low bandwidth networks that is most famously deployed in the Facebook Messenger mobile app. It uses a publish/subscribe (or client/server) model. Elements of MQTT are clients (which can be both publisher and subscriber), servers (also referred to as brokers), sessions, subscriptions and topics. Like HTTP, the MQTT protocol is asymmetric in that it distinguishes between two different roles: client and server.
In MQTT terms, a client is a program or device that uses MQTT. It always establishes the network connection to the server. A client can                Publish application messages that other clients might be interested in.        Subscribe to request application messages that it is interested in receiving.        Unsubscribe to remove a request for application messages.        Disconnect from the server.        
An MQTT server is an entity that accepts connections from clients. Unlike HTTP it generally does not run any application logic, instead an MQTT Server acts as an intermediary between clients publishing application messages and the clients which have subscribed to receive them.
Topics are the “Q” in MQTT—they are named message queues maintained by the server in order to link publishers with subscribers. An MQTT client assumes the role of publisher when it issues a PUBLISH message to an MQTT server (e.g., an instruction to deliver the opaque message payload to any client subscribed to the supplied topic name), and assumes the role of subscriber when it issues a SUBSCRIBE message to the MQTT server (e.g., an instruction to receive any PUBLISH messages that match the supplied topic filter). A topic filter is an expression contained in a subscription, to indicate an interest in one or more topics. A topic filter may include wildcard characters. PUBLISH messages are delivered with one of three QoS levels of assurance, such as at-most-once, at-least-once, exactly-once.
Sessions and subscriptions represent two levels of attachment between a client and a server. A session is a stateful interaction (e.g., an active TCP/IP network connection) between a client and a server, and is identified by a unique client identifier. A session can be established only by a client sending a CONNECT message to a server. Flags in the CONNECT, PUBLISH, and SUBSCRIBE messages determine how session state is maintained if a session is disconnected.
Domain Name System (DNS)
The Domain Name System (DNS) is defined in RFC 1035. DNS is not a type of message bus or middleware, rather it is a hierarchical naming system built on a distributed database for computers, services, or any resource connected to the Internet or a private network. It is designed to associate IP addresses with domain names assigned to each of the participating entities.
Domain Name System-Service Discovery (DNS-SD)
DNS based Service Discovery (DNS-SD) is not a type of message bus or middleware, rather it is a protocol that uses standard DNS programming interfaces, servers, and packet formats to support discovery of network services. Given a type of service that a client is looking for and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service using standard DNS queries.
A particular service instance can be described using a DNS service location record (SRV) as discussed in RFC 2782 and DNS text record (TXT) as discussed in RFC 6763. The SRV record has a name of the form “<Instance>.<Service>.<Domain>” and gives the target host and port where the service instance can be reached. The DNS TXT record of the same name gives additional information about this instance in a structured form using key/value pairs (e.g., scl=<uri_path_to_sclBase>). A client discovers the list of available instances of a given service type using a DNS query for a DNS pointer record (PTR), as discussed in RFC 6763, with a name of the form “<Service>.<Domain>”, which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs. A client can then perform a second DNS query to retrieve the SRV/TXT record pair(s) and get the discovery information contained within these records. Using this discovered host, port, and additional discovery information; a client can then access/invoke a service of interest.
oneM2M Service Layer
Service Layers are a set of protocols that define how services interact with applications and other services. The oneM2M Service Layer is organized as a set of common functions (or service capabilities), an instantiation of which is referred to as a common services entity (CSE), as discussed in oneM2M TS-0001 Functional Architecture. These common functions are exposed via the Mca, Mcc, and Mcn reference points as shown in FIG. 3 and FIG. 4. FIG. 4 also highlights the Msc reference point. The Msc reference point specifies set of interactions between the service Capabilities of different Service Components. The realization of the interaction between the Services Capabilities is implementation specific as discussed in oneM2M TS-0007 Service Component Architecture.
The Mca reference point designates communication flows between an application entity (AE) and a CSE, while the Mcc reference point designates communication flows between two CSEs in the same M2M service provider domain. Communications across Mca and Mcc take place via paired request/response messages, wherein each request performs a specific RESTful operation (e.g., Create, Retrieve, Update, Delete) upon a resource hosted on the targeted CSE. Mcc′ is used between CSEs located in the infrastructure domain of different M2M SPs. Mcn is used between a CSE and an underlying network services entity (NSE) for services other than transport and connectivity.
CSEs are hosted on architectural entities referred to as “nodes”. A node is a functional entity that contains a) one CSE and zero or more AEs, or b) one or more AEs. Services that are provided by CSE's may vary from a temperature sensor service that is implemented on a low cost device to a billing system that is deployed on a large network server. Thus, the architecture is well suited for utilizing a messaging protocol.